Affected versions

• 90.0a1

Affected platforms

• Windows 7

Steps to reproduce
Preconditions

• Make sure the following prefs are set:
  • app.update.log=true
  • app.update.background.loglevel=debug
  • app.update.background.scheduling.enabled=true
• Make sure the When Firefox/Nightly is not running option is checked inside about:preferences
• A task scheduler for the Background Update Agent can be found inside Task Scheduler Library

1. Open the browser console
2. Install a langpack
3. Go to the Task Scheduler Library

Expected result

• The message inside the console reflects the fact that the task is deleted
• The Background Update task scheduler is removed

Actual result

• The following message is displayed inside the browser console:
  BackgroundUpdate: maybeScheduleBackgroundUpdateTask: not scheduling background update: '["app.update.langpack.enabled=true and at least one langpack is installed"]' BackgroundUpdate.jsm:467
  BackgroundUpdate: maybeScheduleBackgroundUpdateTask: exiting after uncaught exception in maybeScheduleBackgroundUpdateTask!
  Exception { name: "NS_ERROR_FAILURE", message: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWinTaskSchedulerService.deleteTask]", result: 2147500037, filename: "resource://gre/modules/TaskSchedulerWinImpl.jsm", lineNumber: 60, columnNumber: 0, data: null, stack: "deleteTask@resource://gre/modules/TaskSchedulerWinImpl.jsm:60:16\ndeleteTask@resource://gre/modules/TaskScheduler.jsm:145:18\nmaybeScheduleBackgroundUpdateTask@resource://gre/modules/BackgroundUpdate.jsm:474:31\n", location: XPCWrappedNative_NoHelper }
• The Background Update task scheduler is not removed and can be triggered

Regression range

• It seems to not be a regression and came with the BUA implementation

Other notes

• Issue not reproducible on Windows 10, the task is removed, no error message is displayed
• If the langpack is installed before the feature is enabled, the langpack policy is respected, the task is not created at all

Can you provide any more information about this? I tried this multiple times and could not reproduce the issue.

I'm using a Windows 7 virtual machine. I tried with a local build and was unable to reproduce, so I tried again with a regular copy of Nightly 90.0a1 installed with the stub installer, and still could not reproduce.

I believe that I followed the preconditions and the steps to reproduce exactly, but I saw no error. And the task was removed, as expected.

Interestingly, if I disable app.update.background.scheduling.enabled instead of installing the langpack, I do get an error. But it's a NS_ERROR_FILE_NOT_FOUND, not a NS_ERROR_FAILURE. And the task does get successfully removed, despite the error. I'm not really sure how to explain this at the moment. But it doesn't seem to be causing any problems, so I'm not sure whether I ought to be that concerned.

I'll try to keep investigating. It is extremely curious that I'd encounter an error through one mechanism and not through the other, since it should be invoking the exact same code in both cases.

Oh, I think I figured out why I'm seeing the NS_ERROR_FILE_NOT_FOUND. It looks like we are attempting to remove the task twice in that case. Not entirely sure why yet.

Ok, I think I know how that duplicate removal is happening. When app.update.background.scheduling.enabled changes, the observer invokes maybeScheduleBackgroundUpdateTask, which invokes _mirrorToPerInstallationPref, which ends up activating the observer for the mirrored pref, which invokes maybeScheduleBackgroundUpdateTask again. I would have thought that the second one to run would have seen that the task was already removed, but I think that instead, the one that runs first sees the existing task, then awaits in _reasonsToNotUpdateInstallation and _reasonsToNotScheduleUpdates, which I believe gives the one that runs second a chance to see the still-existing task. This results in both invocations trying to delete the task.

To be clear: this does not seem to be related to the originally reported problem, nor does it seem like this could cause any functional problems. I'll file a bug to address it at a later time, but it doesn't seem urgent.

Filed as Bug 1712985

I can reproduce this issue both with .exe and stub installer. I've double checked with Gabi on another Windows 7 and she has the same "NS_ERROR_FAILURE" message. I’ve attached a screencast with the problem. Let me know if this is enough or I should provide something more specific.

I was able to reproduce this on one VM (a Win7 Enterprise IE8 tester, I needed to turn up UAC from Off to Default to get the repro) but not another (unpatched Win7 Pro).

I'm still not sure of the cause, or if it's the same failure more you're seeing. It seems to be related to permissions:

• It didn't reproduce for me until I turned up UAC, which changed the ownership of the task folder as created by the WDBA during installation.
• I see HRESULT 0x80070005 when it fails, which is access denied.
• Don't do this: I opened C:\Windows\System32\Tasks in File Explorer, it prompted me to elevate; if I accept that, it permanently adds permissions for my user to Tasks, inherited by all subfolder, and then the task deletion worked. But my user already had full permissions on BUA task itself.
• But permissions are the same on VMs that didn't show the issue at all, so it really doesn't seem like the permissions alone are to blame.

It may be helpful to have some more info, please take these steps:

1. Run winver and collect the version info there (a screenshot of the dialog works).

2. Try this build with more logging: 32-bit installer, 64-bit installer (treeherder).

Run these commands in cmd.exe to set the logging environment variables:

setx MOZ_LOG taskschd:5,sync
setx MOZ_LOG_FILE C:\ProgramData\taskschd

and then install and run to reproduce the bug. When Nightly starts up it should create a file named taskschd.moz_log in C:\ProgramData, please collect the contents of that after the failure.

3. From an elevated command prompt, run:

icacls C:\Windows\System32\Tasks
icacls C:\Windows\System32\Tasks\Mozilla
icacls "C:\Windows\System32\Tasks\Mozilla\Firefox Nightly Background Update 6F193CCC56814779"

and copy the output of each command.

4. Later, if this isn't a throwaway VM, you should run this to unset the environment variables:

setx MOZ_LOG ""
setx MOZ_LOG_FILE ""

Thank you for your help in figuring this out.

Issue is reproducible with Windows 7 x64 Version 6.1 (Build 7601: Service Pack 1) UAC Default admin user with the both 32bit and 64bit treeherder builds.
I've attached the browser console logs, cmd output and the taskschd.moz_log.

I will let as well a comment here since at this moment I can no longer reproduce this issue and I didn't figure it yet why. At first, today, I was able to reproduce it and I've ended up with the information below (I only have a x32 Windows 7 at my disposal).

32-bit installer

• Taskschd.moz_log content
  [Parent 6344: Main Thread]: I/taskschd GetTaskFolder("\Mozilla")
  [Parent 6344: Main Thread]: I/taskschd GetTaskFolder("")
  [Parent 6344: Main Thread]: I/taskschd GetTaskFolder("\Mozilla")
  [Parent 6344: Main Thread]: I/taskschd GetTaskFolder("\Mozilla")
  [Parent 6344: Main Thread]: I/taskschd DeleteTask("\Mozilla", "Firefox Nightly Background Update 6F193CCC56814779")
  [Parent 6344: Main Thread]: I/taskschd GetTaskFolder("\Mozilla")
  [Parent 6344: Main Thread]: E/taskschd ITaskFolder::DeleteTask hr=-2147024891

• cmd content
  C:\Windows\system32>icacls C:\Windows\System32\Tasks
  C:\Windows\System32\Tasks BUILTIN\Administrators:(CI)(F)
  BUILTIN\Administrators:(OI)(R,W,D,WDAC,WO)
  NT AUTHORITY\SYSTEM:(CI)(F)
  NT AUTHORITY\SYSTEM:(OI)(R,W,D,WDAC,WO)
  NT AUTHORITY\Authenticated Users:(CI)(W,Rc)
  NT AUTHORITY\NETWORK SERVICE:(CI)(W,Rc)
  NT AUTHORITY\LOCAL SERVICE:(CI)(W,Rc)
  CREATOR OWNER:(OI)(CI)(IO)(F)
  Successfully processed 1 files; Failed processing 0 files
  C:\Windows\system32>icacls C:\Windows\System32\Tasks\Mozilla
  C:\Windows\System32\Tasks\Mozilla BUILTIN\Administrators:(I)(CI)(F)
  BUILTIN\Administrators:(I)(OI)(IO)(R,W,D,WDAC,WO)
  NT AUTHORITY\SYSTEM:(I)(CI)(F)
  NT AUTHORITY\SYSTEM:(I)(OI)(IO)(R,W,D,WDAC,WO)
  NT AUTHORITY\Authenticated Users:(I)(CI)(W,Rc)
  NT AUTHORITY\NETWORK SERVICE:(I)(CI)(W,Rc)
  NT AUTHORITY\LOCAL SERVICE:(I)(CI)(W,Rc)
  CREATOR OWNER:(I)(OI)(CI)(IO)(F)
  Successfully processed 1 files; Failed processing 0 files
  C:\Windows\system32>icacls "C:\Windows\System32\Tasks\Mozilla\Firefox Nightly Background Update 6F193CCC56814779"
  C:\Windows\System32\Tasks\Mozilla\Firefox Nightly Background Update 6F193CCC56814779 P6022\anca.soncutean:(R)
  BUILTIN\Administrators:(I)(R,W,D,WDAC,WO)
  NT AUTHORITY\SYSTEM:(I)(R,W,D,WDAC,WO)
  P6022\anca.soncutean:(I)(F)
  Successfully processed 1 files; Failed processing 0 files

But for some reason, after several attempts, I can no longer reproduce the issue, no matter the build I install (I’ve tried to use a clear environment for every installation), the task is removed, no error is triggered. The UAC prompt setting is still set as Default, the only additional thing I did as far as I remember was to deny the UAC prompt at one of the installations, but i don’t think this was necessarily the reason to fix it. For the purpose of comparison with the same 32-installer, I will provide the same content after the issue was no longer reproducible under the same system.

• Browser console content:
  BackgroundUpdate: maybeScheduleBackgroundUpdateTask: not scheduling background update: '["app.update.langpack.enabled=true and at least one langpack is installed"]' BackgroundUpdate.jsm:467
  BackgroundUpdate: maybeScheduleBackgroundUpdateTask: witnessed falling (enabled -> disabled) edge; deleted task Firefox Nightly Background Update.

• Taskschd.moz_log content:
  [Parent 5228: Main Thread]: I/taskschd GetTaskFolder("\Mozilla")
  [Parent 5228: Main Thread]: I/taskschd GetTaskFolder("")
  [Parent 5228: Main Thread]: I/taskschd GetTaskFolder("\Mozilla")
  [Parent 5228: Main Thread]: I/taskschd GetTaskFolder("\Mozilla")
  [Parent 5228: Main Thread]: I/taskschd DeleteTask("\Mozilla", "Firefox Nightly Background Update 6F193CCC56814779")
  [Parent 5228: Main Thread]: I/taskschd GetTaskFolder("\Mozilla")

• cmd content
  C:\Windows\system32>icacls C:\Windows\System32\Tasks
  C:\Windows\System32\Tasks BUILTIN\Administrators:(CI)(F)
  BUILTIN\Administrators:(OI)(R,W,D,WDAC,WO)
  NT AUTHORITY\SYSTEM:(CI)(F)
  NT AUTHORITY\SYSTEM:(OI)(R,W,D,WDAC,WO)
  NT AUTHORITY\Authenticated Users:(CI)(W,Rc)
  NT AUTHORITY\NETWORK SERVICE:(CI)(W,Rc)
  NT AUTHORITY\LOCAL SERVICE:(CI)(W,Rc)
  CREATOR OWNER:(OI)(CI)(IO)(F)
  P6022\anca.soncutean:(OI)(CI)(F)
  Successfully processed 1 files; Failed processing 0 files
  C:\Windows\system32>icacls C:\Windows\System32\Tasks\Mozilla
  C:\Windows\System32\Tasks\Mozilla BUILTIN\Administrators:(I)(CI)(F)
  BUILTIN\Administrators:(I)(OI)(IO)(R,W,D,WDAC,WO)
  NT AUTHORITY\SYSTEM:(I)(CI)(F)
  NT AUTHORITY\SYSTEM:(I)(OI)(IO)(R,W,D,WDAC,WO)
  NT AUTHORITY\Authenticated Users:(I)(CI)(W,Rc)
  NT AUTHORITY\NETWORK SERVICE:(I)(CI)(W,Rc)
  NT AUTHORITY\LOCAL SERVICE:(I)(CI)(W,Rc)
  CREATOR OWNER:(I)(OI)(CI)(IO)(F)
  P6022\anca.soncutean:(I)(OI)(CI)(F)
  Successfully processed 1 files; Failed processing 0 files
  C:\Windows\system32>icacls "C:\Windows\System32\Tasks\Mozilla\Firefox Nightly Background Update 6F193CCC56814779"
  C:\Windows\System32\Tasks\Mozilla\Firefox Nightly Background Update 6F193CCC56814779: The system cannot find the file specified.
  Successfully processed 0 files; Failed processing 1 files

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #6)

1. Run winver and collect the version info there (a screenshot of the dialog works).

• I have the same OS version as Gabi mentioned above - https://drive.google.com/file/d/1FnkN0IDYT-H8DEJY55gXBlclC_xr5GvR/view?usp=sharing

Firefox versions >= 116 no longer support Windows versions < 10.

If this never reproduced on Win10+, then it doesn't seem like we need to leave this open anymore.